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Abstract. This paper presents BREW (Breakable Web Application), a 
tool for teaching IT Security. BREW’s main teaching targets are identifi¬ 
cation and exploitation of vulnerabilities, using technologies and method¬ 
ologies for software auditing and testing, and bug detection, fixation, and 
writing of secure code. Main advantages of BREW include that it is easy 
to apply in practice, it is a perfect tool to create and retain motivation, 
it corresponds to the demands of the psychology of learning, and it can 
be used for a heterogeneous group of students. BREW has been success¬ 
fully used for teaching IT Security in Germany as well as on an Erasmus 
Project with international student groups. 


1 Introduction 

As a reaction on Snowden’s disclosure of the gigantic scope of spying on IT 
infrastructure by the NSA press coverage on the topic IT security has increased. 
It is very likely that the number of students interested in attending IT security 
lectures or even the number of IT security study programs will increase. An 
efficient and motivating way to teach IT security is needed, and the lessons taught 
should be easy to apply on future software engineering projects of the students. 
Teaching as many computer science students as possible how to write secure 
code, is a good way to raise the security level of systems in the future. Nowadays, 
many security vulnerabilities exist because programmers are not aware of IT 
security when writing code. For example, the OWASP Top Ten project [T] lists 
the most common security vulnerabilities of web applications. The most common 
security vulnerability of this list, called ’’Injection”, can easily be avoided if the 
programmer is aware of this problem. Avoiding SQL Injection, the most common 
injection, requires only using a special function call to the database. Injection 
being the commonest vulnerability of web application shows, that there is a great 
demand for security education with web programmers. 

When teaching secure code writing, different approaches could be chosen: 

— The Hacking Approach: students search for vulnerabilities in web applica¬ 
tions and exploit these vulnerabilities 


— The Developer Approach: students are tought coding guidelines to avoid 
vulnerabilities 

The first approach teaches students to think like a hacker. This state of mind 
includes doing things in an unusual way to find vulnerabilities. It is the aim of 
the hacker to find ways to use the system that the programmer did not consider. 
Blind spots of developers may lead to vulnerabilities of software. However, the 
hacking approach falls short because it is a destructive approach: it tells how to 
break software, not how to protect software from an attack. 

In contrast, the second approach is a constructive approach: rules are pre¬ 
sented, that help to write secure code, hence reduce the number of vulnerabilities 
that will exist in software. However, a rules based approach does not support 
a deeper understanding of IT security and it does not help students to under¬ 
stand how attacks work. Especially, students do not learn to think ’’outside the 
box” like an attacker would do. Both approaches can be applied to lab sessions: 
hacking labs or secure software development labs. However, most teaching tools 
available today do not offer the combination of both approaches. 

BREW (Breakable Web Application) implements both approaches and hence 
is an ideal tool to teach IT security. 

This paper is structured as follows: The next section gives an overview of 
BREW. Section [3] compares BREW to other tools for teaching security of web 
applications. Section [4] presents the educational design of BREW. The section [5] 
shows the technical design as well as some usage scenarios, followed by the sec- 
tion[6]with different deployment targets. Section [7] summarises some experiences 
with BREW from classroom use at Munich University of Applied Sciences and 
the Erasmus Intensive Learning Program ” Secure Web Applications”. Section [8] 
concludes the paper and gives an outlook on work in the future. 


2 Overview 

BREW is a platform for hands-on teaching of writing secure web applications. 
The main idea of BREW is to have a web application with many security vulner¬ 
abilities. Following the topics of the associated lecture, students first try to find 
one or more vulnerabilities of the web application. Each identified vulnerability 
should then be exploited by the students. Following this hacking part of a lab, 
the students change to the source code of the application. They are asked to 
identify the lines of code, that introduce the vulnerabilities they exploited be¬ 
fore. Then the students have to fix the vulnerability. At the end of a web session, 
the students try to hack the fixed application again and hopefully they are not 
successful. Figure [l] gives a schematic overview for this process. 

To summarise, BREW is designed with the three educational targets given 
in table [T] 

To be able to use BREW in labs with heterogeneous hardware, it is realised 
as a virtual machine image in OVA format. OVA can be used in virtualization 
environments like VirtualBox [2] (client) or qemu-KVM |3]. The virtualization 



Fig. 1 . Student workflow 
Table 1 . Educational targets 


Identification Target 

T1 Identification and exploitation of vulnerabilities 

T2 Technologies and methodologies for software auditing and testing 

T3 Bug detection, fixation and write secure software 


approach makes BREW platform independent as VirtualBox is available on a 
wide range of operation systems, including Windows, MacOS, and Linux. The 
technical design of BREW allows it to run as a local virtual machine (e.g. on a 
lab computer or on the laptop of students) or even in a cloud environment like 
CloudStack [4j , OpenStack [5] or Amazon Cloud [6] (not full featured yet). 

Inside the virtual machine, BREW is realised as an Integrated Development 
Environment (IDE) project. Students start the web server by a ’’play” button of 
the IDE projects. They connect to the web application by the installed browser. 
Hacking is done in the browser or using external tools also installed in the virtual 
machine. Working with code takes place in the IDE. 

The most important goals of BREW is to teach useful secure code writing for 
real world software engineering projects. To do so, it is very important that the 
selection of vulnerabilities covered by BREW is relevant to real world software 
projects. We chose to base the selection of vulnerabilities on the OWASP Top 
















Ten project [T|. The OWASP Top Ten project lists the most common attacks on 
web applications. The current top ten list is from the year 2013, so it is quite 
new. Table [2] lists the current top ten list. BREW includes vulnerabilities that 
enable the attacks A1-A3, A5 - AS, and A10 from this list. 


Table 2. Owasp Top Ten Attacks 


Identification Attack type 

A1 

Injection attacks 

A2 

Broken Authentication and Session Management 

A3 

Cross Site Scripting 

A4 

Insecure Direct Object References 

A5 

Security Misconfiguration 

A6 

Sensitive Data Exposure 

A7 

Missing Function Level Access Control 

A8 

Cross Site Request Forgery 

A9 

Components with Known Vulnerabilities 

A10 

Unvalidated Redirects and Forwards 


To deal with the heterogeneous background of students regarding knowledge 
of relevant technologies as well as to allow a personal learning process, four 
different stages of complexity of vulnerabilities exist in BREW. BREW implies, 
that a student with basic knowledge of Java and knowledge from the associated 
lecture can deal with the first three stages. The fourth stage is mentioned as 
special challenges and is used for further self educational of the students. More 


details on stages is given in section 5.1 


3 Related Work 


One of the best known platforms for lectures in web application security is 
WebGoat [7]. Based on java and J2EE it provides different lessons and exercises 
related to it-security. It consists of different lessons exploitable for students. It 
aids students with an inbuilt help system and provides solutions for the exer¬ 
cises. However WebGoat is suitable for the most lectures, depending on black 
box testing. The main target relays on detecting vulnerabilities. The fixation or 
closing of flaws is not in scope of WebGoat. This is one of the main differences 
to BREW. 

Most similar to BREW is the Damn Vulnerable Web Application [Sj. It pro¬ 
vides different stages in complexity (like BREW) and gives hints for the ex¬ 
ploitable parts. It depends on php and mysql and is also available as virtual 
machine. It provides black box and white box testing features. However, the ap¬ 
plication has only a small amount of vulnerabilities, and the educational concept 
seems enhanceable. There is no explanation for the different vulnerabilities or 






the solution. And unlike BREW it does not have the look and feel of a normal 
web application. 

An online solution is presented in Hackthissite [9]. It consists of different ex¬ 
ercises with different stages of complexity. While the source code is not available 
it is only suitable for black box testing. The fixation of the vulnerabilities is out 
of scope from this approach. 

4 Educational Design 

This section describes the educational concept behind BREW in IT-Security 
lectures. The educational concept behind BREW offers four major advantages: 
it is easy to apply in practice, it is a perfect tool to create and retain motivation, 
it corresponds to the demands of the psychology of learning and it can be used 
for a heterogeneous group of students. 

Since BREW is an open source application and there is no need for further 
installation or configuration, BREW circumvents any obstacles that students 
and/or lectures could have. BREW can be easily explained to lecturers, tutors 
and students and its system is immediately applicable. There is no need for 
specific hardware or software and it can be used for groups as well as for single 
students. In sum: after a short introduction BREW is ready to use for every 
kind of IT-Security lecture. From an economic perspective BREW satisfies the 
most important requirements: time and money. But what about the advantages 
of the concept behind BREW when it comes to the motivation of students? 
There are many different theories and ideas about the way in which lectures 
should be designed that students can learn as much as possible. One of the most 
important and even more often unconsidered fact is motivation. The biggest 
challenge for the lecturer is to motivate the students to an extent that they are 
willing to learn and willing to throw themselves into complex subjects, even if 
they are struggling nan!- But how can you create and retain motivation during 
a semester? And moreover: how can you build an educational design that creates 
motivation and covers the approached content of the lecture? According to the 
ARCS model designed by Keller there are four important elements that a lecture 
should generate in every single student: Attention, relevance, confidence and 
satisfaction |l2ll3ll4j . Attention means that a lecture must contain interesting 
examples, mental challenges and information which are in a personal and/or 
emotional way important for the student. Relevance can be provided by revealing 
the intended goal of the lecture. Moreover the lecture should inspire the student 
with confidence the student should know that even if the lecture is sometimes 
hard to understand or to put in practice, at the end he or she will manage 
all difficulties and rise to the challenge. And last, there should be satisfaction. 
Every learning cycle should offer the possibility to achieve a goal. Therefore the 
learning cycle must be adoptable to the different skill levels of every attending 
student. 

BREW contains all four elements. First, it is a perfect and most realistic 
example for vulnerabilities every major company has to face with. Students can 






get a realistic insight what secure software has to supply and which are the most 
popular problems it has to strive against. Second, right at the beginning the 
three major targets are identified: the identification and exploitation of vulner¬ 
abilities, the knowledge of technologies and methodologies for software auditing 
and testing, further the bug detection, fixation and writing of secure software. 
Third, BREW offers a manual which makes it possible to offer immediate help 
if the student is struggling with some problems. Due to the fact that BREW 
works with different skill levels, in the fourth place every student has the chance 
to solve successfully the given tasks. Moreover, students experience the challenge 
for further research or knowledge. As you can see, BREW is the ideal way to 
provide a lecture that can create and retain the motivation for (almost) every 
student who is interested in the field of IT security. But BREW has some more 
educational advantages to offer. 

According to the psychology of learning, a successful learning behaviour de¬ 
pends not only on the individual learning rate and strategy of a student, but 
also on the way the content of a lecture is presented to the students. There¬ 
fore the lecture must be structured according to the following three principles. 
First, a logical design and a logical chain of thought; for example a connection 
between different kind of problems or dependencies among software elements. 
Second, a specific user experiment which appeals to all senses. Third, a lecture 
should be earmarked to a specific purpose. The whole structure of a lecture must 
therefore reflect the learning target USEE!. BREW can also cope with those 
three requirements. All challenges are built systematically on one another. By 
using BREW students have a one on one real-time user experiment: the way in 
which BREW works is exactly the same way every secure software works and 
it represents for example the bug fixation realistically. Thus BREW reflects the 
learning target on all levels in a perfectly matched way. Therefore BREW is the 
ideal instrument to face one of the biggest challenges - the heterogeneous groups 
of students with different skill levels. 

Over the recent years lecturers experienced that an increasing number of stu¬ 
dents show difficulties in the acquiring of software knowledge as well as in coping 
with the study process itself. One reason for this negative trend can be found 
in the significant deficiencies in certain base competencies like self-, practical or 
cognitive competencies that are relevant for successfully studying software re¬ 
lated topics HHj- In order to face and overcome those difficulties, lecturers must 
seek different kinds of Software Engineering education tools. Fortunately BREW 
could be one of those required tools. 

BREW challenges a wide range of the most important competencies for the 
acquiring of software knowledge like reading skills, systematic and methodical 
acting, understanding of written instructions, abstract thinking as well as act¬ 
ing in a goal-oriented way. Moreover, students who are using BREW exceed the 
learning of pure knowledge but rather learn the active application. Therefore 
BREW gives the opportunity to cover the deficits in those skills in a motivating 
and challenging way for students with different competency levels. 




5 Technical Design and Usage Scenarios 


This section describes the technical design in detail. BREW is quite flexible, can 
be adapted and is useful in many scenarios. This sections shows some common 
usage scenarios. 

5.1 Stage Design 

To deal with different technical backgrounds of students as well as with lecture 
process and to keep hacking interesting for the students, BREW offers stages 
with different complexity. The higher the complexity, the harder it is either to 
identify or to exploit a vulnerability. The first three stages are used for common 
labs. The fourth stage is very difficult to master, hence remains an open challenge 
for the best of the students, to give them an incentive for further improvement 
outside of the classroom. Table [3] lists the definition of stages. 


Table 3. Different complexity stages 


Identification Target 

Cl 

Easy to fix and identify 

lecture 

C2 

Target to reach for most of the students practical work 

C3 

Target to reach 100 percent in grading 

practical work 

C4 

Challenge for lecture 

Extra work for deep knowledge 


Stage one vulnerabilities (Cl) are easy to find, easy to exploit, and easy to fix. 
The vulnerabilities were shown in a very similar form in the lecture to show the 
concept of the vulnerability. Stage one vulnerabilities provide fast success and 
hence support a positive attitude towards BREW, motivate, and make eager to 
find vulnerabilities of the next stages. 

Stage two vulnerabilities ( C2) are designed for practical lessons and are suit¬ 
able for the most common problems in IT-Security. A stage two vulnerability is 
designed as a flaw without any side effect. It can be found and fixed with best 
practice patterns presented in common textbooks. 

Stage three vulnerabilities ( C3) require a good understanding of IT security 
and web technologies to identify, explore, and fix. Stage three vulnerabilities 
combine different technologies and knowledge areas. Some built-in traps may 
decoy the solution. Stage three vulnerabilities are enhanced vulnerabilities that 
can be found out in the wild very often. 

Stage four vulnerabilities (C4) are special challenges that are outside of the 
scope of bachelor or master lectures. They are designed as very sophisticated 
problems in IT-Security. A challenge is meant for individual learning or class¬ 
room contests. Some of these challenges are not solved by students yet. Usually, 
the best students of the course can find, exploit, and fix at most one stage four 
vulnerability during a semester. Special care is taken that solutions of challenges 





do not leak to public. Until all challenges are mastered, a lecturer needs a per¬ 
sonal identification to get the solution for the challenges from the BREW team. 


5.2 Educational Usage Scenarios 

BREW was not only designed to deal with heterogeneous hardware and software 
environments, it also was designed to be flexible in how it is used in teaching. 
Some of the possible usage scenarios are described in the following. Usage sce¬ 
narios include White Box Testing, Black Box Testing, and Hackveloper. 


White Box Testing Scenario For White Box Testing, the student has access 
to the source code as well as to the running application. The scenario simulates a 
typical industrial quality testing in software development. Common used white 
box testing tools are already integrated into BREW. This includes tools for 
manual audits as well as tools integrated into the IDE like pattern matching or 
data flow analysis. BREW ensures success for different White Box Testing tools. 


Black Box Testing Beside White Box Testing, BREW can be used for Black 
Box Testing. Black Box Testing differs from White Box Testing in that the 
students do not have access to the source code of the application. To do so, 
BREW can be deployed as pure server with the command line. It is designed 
to deal with common vulnerability testing tools (see table [4]). The Black Box 
Testing scenario simulates the work of a typical penetration tester. 


Table 4. Examples for common black box testing tools 


Identification Target 

TS1 BurpSuite 

TS2 Owasp Zap 

TS3 Metasploit 

TS4 nmap, dnsmap, hping3 


Hackveloper Neither the White Box Testing nor the Black Box Testing ap¬ 
proach helps students to write secure code. The third scenario, called Hack¬ 
veloper, is the envisioned use of BREW. Students are not only asked to identify 
and exploit vulnerabilities, they also must fix any vulnerability they find. In com¬ 
parison to the other two approaches, students can find and fix vulnerabilities. 
Naming Implementation of functionality follow Best Practice Patterns similar to 
(19120121] and [SZj ■ This ensures that students are able to find similar problems 
within common literature or online documentations. 







5.3 Architecture and General Implementation 

The architecture of the web application follows the MVC (Model-View-Controller) 
pattern. The implementation of BREW uses the Spring [23] framework. The 
Spring framework is a lightweight platform for java applications. 

BREW uses Java as it is a well known, well documented and widely used pro¬ 
gramming language. However most of the built-in vulnerabilities are independent 
from the underlying language. 

A schematic overview is given in Figure [2] 



Fig. 2. BREW architecture 


At first, the browser sends a request to the web application. Within the path 
matching of the Spring framework a controller method gets called, see listing 
1. In this example the search page is mapped to http://mydomain/search, secu. 
For simplicity every logical component has a related controller class (e.g., Search 
page —► SearchController.java). Every action within this logical component in¬ 
herits a method (p.Ex search —> searchWebWithPost(...)). 

Listing 1. Example for search controller 

(3RequestMapping (value = "/search.secu", method = RequestMethod.POST) 
public ModelAndView searchWebWithPost( 

ORequestParam(value = "search", required = false) String search) { 









ModelAndView mv = new ModelAndViewO'search") ; 
mv.addObjectO'searchString", search); 
return mv; 

> 

This method implements the business logic. It produces a HashMap-based 
model for further usage in the related view. See Listing 2 for the model. In this 
example, the view gets the variable search accessible with the key searchstring. 

Listing 2. Injection of a model 

mv.addObj ect("searchstring", search); 

As shown in Listing 3 the view with the name search will be used. In the 
case of BREW a view name automatically links to a java server page with the 
suffix .jsp. In this case it will be search.jsp. 

Listing 3. Creation of a view 

ModelAndView mv = new ModelAndView("search"); 
return mv; 

The given model ensures that students need to understand the dependency 
between the controller method and the related view to solve all stage one to 
stage three problems. Understanding the Model-View-Controller pattern is very 
important for understanding the security of web applications. 

5.4 Vulnerabilities 

Vulnerability design in BREW follows common flaws in web applications. These 
common flaws can be classified as given in table [5] 


Table 5. Different vulnerability types 


Identification Vulnerability type 

FI 

Bad programming style 

F2 

Design and architecture flaws 

F3 

Wrong implementation of basic concepts 

F4 

Vulnerable environment 


For example, a bad programming style FI can be found in an SQL injection 
vulnerability (stage two vulnerability). Listing 4 shows an example of the vul¬ 
nerability. To make the problem harder, most of the SQL query is validated as 
proposed as best practice in the associated lecture. However, string concatena¬ 
tion is used for the last variable uid as a programmer that does not understand 
the problem of SQL injection would probably do. Concatenating uid to the SQL 





query allows a successful SQL injection. As some of the variables of the SQL 
ciuery are correctly validated, finding the vulnerability is made more difficult. 

An attacker can dispose any valid sql-code over this variable. 

Listing 41. Example for bad programming style 

String sql = "update M_USER set " + 

"muname = ?, " + 

"mpwd = ? " + 

"where " + 

"ID = "+uid; 

jdbcTemplate.update(sql, 

new Object [] {uname, upwd}-, 

new int[]{Types.VARCHAR, Types.VARCHAR}); 

> 


Design and architecture flaws F2 are introduced into source code by bad 
planning. One example for a design flaw in BREW are data access functionali¬ 
ties: there is no single point of validation but validation has to be implemented 
on multiple points for each function in BREW. This is very bad design. Vulner¬ 
abilities are introduced into BREW by forgetting some validations on purpose. 

The third flaw is wrong implementation of basic concepts F3. BREW imple¬ 
ments a buggy storage of passwords. The common concept of password storage 
is to use salted hashes. In BREW, the admin password is secured without a 
salt and with the weak md5 algorithm. The password hash can be found in a 
rainbow table as the admin uses a bad password. In this case a simple google 
ciuery results to the origin password. 

Another class of flaws is the use of weaknesses of used frameworks F4- An ex¬ 
ample for a vulnerability of this class in BREW is that the management platform 
of the embedded tomcat uses the default password. Within this vulnerability an 
attacker can take over the full application. 


5.5 Extensibility 

BREW is an open source project. The first release will be able at github. At the 
moment it is a release candidate with a few minor fixation needed. It is planned 
to build an open community to extend BREW. 

The current version of BREW implements common functionalities for a web 
application. Hence BREW is designed to work with only less configuration over¬ 
head it is easy to extend. A new functionality, vulnerability or page can be 
integrated by writing a new class or bunch of classes. The registration of an 
extension is done with spring annotations. 

However it is also possible to build new web services by extending the con¬ 
figuration of the built-in Tomcat server. 

BREW gets compiled whenever restarting the Webserver. New libraries, source 
files or binaries are inherited when present under the main BREW directory tree. 



To extend a lecture, a developer just needs to copy the new files to BREW. A 
makefile in the root directory can be used to pack the new BREW distribution. 
This functionality is explained in detail in the developer handbook. 


6 Deployment 

BREW was designed to deal with heterogeneous hardware and software environ¬ 
ments. Some of the possible deployment scenarios are described in the following. 


6.1 Vulnerability Selection 

BREW has a modular design. Lecturers can deploy BREW with selected vul¬ 
nerabilities or with the complete set. In all cases BREW can be installed by 
unpacking a single file. To fulfil different requirements for different lectures, the 
lecturer can build an adapted version of the application for each lecture or even 
different groups of students. Selection of vulnerabilities and functionalities for 
the final BREW deployment is possible by using compile flags of the makefile. 
However, complex dependencies may exist between stage three and stage four 
vulnerabilities. Table [6] describes dependencies and the resulting constraints in 
the selection of vulnerabilities. 


Table 6. Configuration level and their dependencies 


Identification Dependency 

Vci veil V■• ■ V vein 

Vc 2 Vci A (vc2i V vc2 n ) 

C3 (Vci A V C 2) 

C4 Challenge for lecture Extra work for deep knowledge 


Within the stages Cl and C2 every Vulnerability can be selected or unse¬ 
lected. The stage C3 needs all vulnerabilities from Cl - C2. Whenever C4 is 
selected, BREW gets build in the full version. 


6.2 The Lecturer’s Cheat Sheet 

Each vulnerability of BREW is well documented. A reference solution on how to 
fix each vulnerability is also provided for the lecturers. BREW also comes with 
python scripts for easy demonstration of exploits. These scripts provide an easy 
way to show the reference solution during a lecture. The scripts may also be used 
to validate the fixed code of the students. Code fixes are proposed as patches. 
With these patches the solution can be explained and ensures that every student 
has the same version of the source code for following lectures. 





6.3 BREW as IDE project 


Originally, BREW is deployed as IDE project. A configuration is prepared for the 
eclipse IDE and IntelliJ. The IDE project includes every dependency and a start 
configuration. This approach allows BREW to be started by clicking the run 
button in the IDE. Whenever the source code of BREW gets changed, the user 
needs to restart the project to deploy his changes. Even a hot deployment while 
debugging is possible in most cases. (Expect for C4 challenges) The project path 
includes a fully qualified git-tree. To update BREW or to get a clean version or 
a version with patches, the user can pull different versions from the remote git 
repository. 


6.4 Local Virtual Machine Deployment and Cloud Deployment 

To ensure that every student has the same environment, BREW is available 
as virtual machine. For use on student laptops or on lab computers, a Virtual 
Box image is used. For deployment in a cloud environment like Cloudstack or 
OpenStack, a version for qemu-KVM exists. Future versions of BREW will also 
be compliant to Amazon Cloud and VMWare ESXI [24]. Using BREW in the 
cloud ensures a fast deployment for large student groups without the overhead 
of local installation. 


6.5 BREW as Target Server 

Without an IDE, BREW can be used as a pure server for Black Box Testing 
as well as a vulnerable target in IT-security research. The server consists of 
BREW and an optional reverse proxy for performance evaluation. With a plain 
installation of Kali Linux in another virtual machine, students have a full set of 
penetration tools and the target. This version is also available for Virtual Box 
and qemu-KVM. 


7 Experiences with BREW 

Since today, BREW has been tested in different lectures and practical lessons. 

— lectures in IT-Security (MUAS) 

— lectures in IT-Forensics (MUAS) 

— lectures in Intrusion Detection (MUAS) 

— Developer Days 2013 (Munich) 

— Erasmus IP Program 2012 (MUAS) 

— Erasmus IP Program 2013 (University of South Wales) 

— Erasmus IP Program 2014 (University of Santander) 

— DOAG Conference 2013 (Nuremberg) 


8 Conclusion 


This paper presented BREW, a flexible, platform-independent tool for teaching 
secure programming of web applications. BREW takes an Hackveloper approach 
in which students not only have to identify and exploit vulnerabilities of web 
applications, but they also have to fix and test the code of a vulnerable web 
application. However, BREW can also be used in many other teaching scenarios, 
e.g., in teaching Black Box Testing or White Box Testing. BREW has been tested 
in national and international teaching settings and proved to be quite useful. In 
the future, BREW will be continuously be extended with new vulnerabilities to 
stay up to date with state of the art of attacks on web applications. BREW 
vulnerabilities will implement vulnerabilities for further versions of the OWASP 
Top Ten project as well as vulnerabilities of other similar lists. 
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